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re Patent Application of: 
KAMAT 

Serial No. 10/780,423 

Filing Date: February 17, 2004 

Confirmation No. 2010 
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NOTIFYING USERS OF AN EVENT 
USING ALERTS 



Examiner: D. Le 



Art Unit: 2683 



DECLARATION UNDER 37 C.F.R. §1.131 



Mail Stop Amendment 
Commissioner for Patents 
P. O. Box 1450 
Alexandria, VA 22313-1450 

Sir: 

I, HARSHAD N. KAMAT, do hereby declare: 

1. I am the inventor of the subject matter of 
the above-identified patent application. 

2. I conceived of the subject matter of the 
above -identified patent application while working in our 
research and development laboratories in the United States 
at TeamOn Systems, Inc. in Issaquah, Washington prior to 
June 13, 2003, the effective date of U.S. Patent Publication 
No. 2005/0027742 to Eichstaedt et al . (hereinafter 
"Eichstaedt") . I conceived the invention that is described 
and claimed in the above- identified patent application and 
worked diligently on developing the claimed invention from 
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the time of conception to a reduction to practice at a date 
before June 13, 2003. 

3. I conceived and reduced to practice a system 
and method for notifying a user of an event in which an 
alert engine module receives an alert in a Simple Mail 
Transfer Protocol (SMTP) indicative of a notification for an 
event corresponding to a stored message on a server, and 
transforms the alert one time from the SMTP into a 
communications format that is preferred by a user. The 
alert is delivered to a target address preferred by a user. 
The alert can be transformed based on a header and/or format 
of the target address. The alert can also be delivered to 
an appropriate gateway for the communications format. This 
alert could be delivered to a mobile device in a 
communications format based on the type of mobile device. 
This communications format could also be a Short Messaging 
Service (SMS) message, which could be a default message. 

4. I had reduced the invention to practice by 
developing appropriate software and testing the software 
prior to the effective date of Eichstaedt as noted in the 
email shown in Exhibits 1 and 3. Exhibit 1 on page 2 sets 
forth that I ran simple tests using the T-Mobile SMSC to 
test throughput. Page 1 sets forth a throughput delivery of 
about 54,000 messages in one hour and the use of SMTP 
servers corresponding, of course, to the Simple Mail 
Transfer Protocol (SMTP) . Mobile phones had been used. The 
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different alerts as noted in the bottom of page 1 were 
indicated as sent previously to MX servers. These emails 
are dated March 13 and 14, 2003, before the effective date 
of Eichstaedt. 

5. Page 2 of Exhibit 2 shows revision 1.1 and is 
directed to results from querying a CVS repository for a 
specific file, i.e., alert engine. java. Other files would, 
of course, make up the alert engine, but this particular 
file is the main entry point into the alert engine module. 
Revision 1.1 states that the initial cut for the alert 
engine would replace SMTP as a preferred delivery agent and 
also support SMPP and PAP. 

6. Page 1 of Exhibit 3 sets forth that a test 
was run with T-Mobile in which 21K alerts were sent at 300 
MSISDNS. The 21K would refer to the alert of a small size 
as compared to a large message. The alert could be 
indicative of a notification for an event corresponding to a 
stored message on a server. I had used a software component 
termed by me as an alert engine module with the server, 
because alerts were being transferred. These emails are 
dated March 22, 2003. 

7. I continued to work diligently with further 
testing and development of the software until filing of this 
patent application identified above. In September 2003, I 
had drafted an Invention Disclosure Form (Exhibit 4) 
initially listing as a joint inventor, Shaibal Roy. After 
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further discussions among us and the patent attorney; I was 
correctly determined to be the sole inventor of the claimed 
invention. The Invention Disclosure Form sets forth in 
detail a block diagram illustrating various components of 
the apparatus /system and method and some written description 
of the invention that had been reduced to practice. 

8. I hereby declare that all statements made 
herein are of my own knowledge and are true and all 
statements made on information and belief are believed to be 
true; and further that these statements were made with the 
knowledge that willful false statements and the like so made 
are punishable by fine or imprisonment, or both, under 
Section 1001 of Title XVIII of the United States Code and 
that such willful false statements may jeopardize the 
validity of the application or any patent issued thereon. 

Date 1 I Harshad N f KAMAT 
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Fwd RE RE TMobile SMSC Accessible 
Forwarded Message 

> From: "Netu, Sorin" <Sorin.Netu@T-Mobi1e.com> 

> To: 'Harshad Kamat' <harshad@TeamOn.com> 

> Cc: Shaibal Roy <shaibal@teamon.com>; Steve McCarthy <sim@teamon .com>; 

> Taylor Clark <taylor@teamon.com>; Michael Zakharoff <zaK@TeamOn . com> ; 

> David Hanson <davidh@teamon.com>; Aaron Roberts <aaron@teamon.com> 

> Subject: RE: RE: TMobile SMSC Accessible 

> Date: Fri , 14 Mar 2003 08:49:44 V0800 
> 

> 

> I see. I will ask the lab SMSC admin to make sure the configuration is 

> what I requested. I was not aware they only allow 1 connection. They 

> were supposed to allow 2. 

> Also I will ask them if they have any procedures for testing the 

> throughput of such an application. 

> 

> The throughput I have asked for is to have 15 SMSs/sec. This 

> translates to 54000 messages in 1 hour. Did you do any analysis on 

> the current situation (SMTP servers) to see what you would need to 

> send all messages wit no problem? Let me know if 15 msg/sec is not 

> enough and we can change. All connections now on the SMSC allow up to 

> 10 msg/sec and we have larger apps then yours in there. Our alerts 

> system from infospace sends more then 5 million messages per month and 10 msg/sec 
are enough. So, please let me know if your forecast exceeds mine. 

> 

> One (short term) way to get around this SIM/SMS storage problem is to 

> send class 0 SMS which is only displayed on the phone instead of class 

> 2 which are stored in the SIM card. Another way would be to set the 

> bit in the header to overwrite the messages (I think this only works 

> if the message content is the same as previous). Try these and in the meantime I 
will work with engineering to see what else we can do. 

> 

> I hope this helps. Thank you 

> 

> Sorin 

> 

> Original Message 

> From: Harshad Kamat [mailto:harshad@TeamOn.com] 

> Sent: Friday, March 14, 2003 8:33 AM 

> To: Netu, Sorin 

> Cc: Shaibal Roy; Steve McCarthy; Taylor Clark; Michael Zakharoff; 

> David Hanson; Aaron Roberts 

> Subject: Re: RE: TMobile SMSC Accessible 
> 

> 

> Original Message — 

> > From: "Netu, Sorin" <Sorin.Netu@T-Mobile.com> I am not sure I 

> > understand what you mean by "any ideas on how to test its 

> throughput 

> > without sending a whole lot of mails". The lab SMSC does not have a 

> > large 

> throughput 

> > and is only meant for testing the functionality. Can you please clarify? 

> 

> Today, we deliver alerts to four MX servers at your end. Previously, 

> you had only two, boca and tofu, and they could not keep up with all 

> the alert traffic. Hence, it would be a good idea to test whether a 

> single SMSC would be able to handle all the traffic before going live with it. 

> 

> Secondly, I was under the impression that the lab SMSC is very similar 

> to the production SMSC. 

> 

> I wanted to test the throughput without sending a lot of mails, say 
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Fwd RE RE TMobile SMSC Accessible 

> 10000 messages, because it we don't have as many SIM cards, each phone 

> has enough memory to take about 30 messages and once delivered it is 

> hard to delete them one by one. 

> 

> Hope that answers your question. 

> 

> in an earlier mail, you said 

> >3)TeamOn is going to have a input/output_window =15 

> >Maxsession=2 

> >Multiple_Address=yes 

> 

> I find that the lab SMSC allows me only one connection at a time. The 

> production SMSC will allow me two connections, could you please ask 

> the administrator to allow TeamOn two connections on the lab SMSC so 

> that I can test in a "production like" environment. 

> 

> Thanks, 

> Harshad 

> 
> 

> > Original Message 

> > From: Harshad Kamat [mailto:harshad@TeamOn.com] 

> > Sent: Thursday, March 13, 2003 6:27 PM 

> > To: Shaibal Roy; David Hanson; Netu, Sorin 

> > Cc: Taylor Clark; Steve McCarthy; Aaron Roberts; Michael Zakharoff 

> > Subject: TMobile SMSC Accessible 

> > 

> > 

> > The TMobile SMSC is now accessible to me and I ran some simple tests 

> > against it. 

> > 

> > I need to test its throughput. 

> > 

> > Sorin, any ideas on how to test its throughput without sending a 

> > whole lot of mails, we have very few SIM cards and it is a pain to 

> > delete all those messages if you don't have "Delete All" on your phone. 

> > 

> > By the way, I need all the Sims and phones I can lay my hands on 

> > tomorrow to run these tests. So, Sorin please return our phones 

> > at the earliest 

> > :-) and Aaron -- allocate all the phones to me when they come in. 

> > 

> > 

> > - 

> > Harshad N Kamat 

> > TeamOn Systems 

> > 425-369-5751 

> > 
> 
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cvslog 

RCS f i 1 e : /var/cvs root/123/agg/com/teamon/apps/al erts/Al ertEngi ne . java , v 

working file: Al ertEngi ne. java 

head: 1.15 

branch: 

locks: strict 

access list: 

keyword substitution: kv 

total revisions: 24; selected revisions: 24 
descri ption: 

revision 1.15 

date: 2004/12/01 02:19:39; author: blair; state: Exp; lines: +5 -5 
Bugld: 0 Removed unreferenced local and private members and methods. 

revision 1.14 

date: 2004/08/27 23:47:09; author: harshad; state: Exp; lines: +36 -9 

Commenting out use of AlertThreadGroup and falling back to old code where in we kept 

a count of active threads. 

The threadgroup was not getting the correct count, the active count was always much 
higher. 

Bugld:SDR34822 
revision 1.13 

date: 2004/08/25 23:08:48; author: harshad; state: Exp; lines: +21 -5 
Bugld:SDR34822 

revision 1.12 

date: 2004/08/03 22:13:22; author: harshad; state: Exp; lines: +12 -31 
Adding AlertEnqineThreadGroup to keep count of active threads and to see if there 
are any uncaught exceptions 
Bugld :0 

revision 1.11 

date: 2004/06/25 00:50:42; author: dave; state: Exp; lines: +5 -6 
Bugld: 000 - Removing unused imports. 

revision 1.10 

date: 2004/05/06 20:55:09; author: harshad; state: Exp; lines: +1 -10 
Removing all traces of bwc/bda code from alert engine. 
Bugld :0 

revision 1.9 

date: 2004/04/07 18:24:03; author: harshad; state: Exp; lines: +6 -2 
Bugld :0 

revision 1.8 

date: 2004/02/06 21:36:21; author: harshad; state: Exp; lines: +5 -3 
branches: 1.8.2; 
Bugld :0 

revision 1.7 

date: 2004/01/13 21:54:07; author: harshad; state: Exp; lines: +13 -1 

Major re-working taking into consideration the new target types that we need to add 

in future -- bwc, oma emn, device specific OTA Prov docs and so on. 

Bugld:0 

revision 1.6 

date: 2003/05/06 00:47:52; author: harshad; state: Exp; lines: +22 -10 
branches: 1.6.8; 

introducing Connection Pooling. Major restructuring of classes. 
Bugid:0 
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revision 1.5 

date: 2003/04/18 18:19:30; 
Bugld:8910 

revision 1.4 

date: 2003/03/27 02:18:13; 
Bugid:0 

revision 1.3 

date: 2003/03/24 18:16:47; 
Bugid:0 

revision 1.2 

date: 2003/03/18 18:23:39; 
branches: 1.2.2; 
Bugld:0 

revision 1.1 

date: 2003/03/14 23:49:33; 



cvslog 

author: harshad; state: 



Exp; lines: +35 -11 



author: harshad; state: Exp; lines: +4 -1 



author: harshad; state: Exp; lines: +7 -3 



author: harshad; state: Exp; lines: +3 -4 



state: Exp; 



author: harshad; 

initial Cut for AlertEngihe which will replace SMTP as the preferred 
delivery agent for TMobile. It supports SMPP and PAP. 
Bugld:0 



revision 1.2.2.3 

date: 2003/04/18 18:26:39; 

Bugld:8910 

revision 1.2.2.2 

date: 2003/03/27 02:18:01; 

Bugld:0 

revision 1.2.2.1 

date: 2003/03/24 18:16:36; 

Bugld:0 



author: harshad; state: Exp; lines: +35 -11 



author: harshad; state: Exp; lines: +4 -1 



author: harshad; state: Exp; lines: +7 -3 



revision 1.6.8.1 

date: 2004/04/07 23:54:25; author: harshad; state: Exp; lines: +6 -2 

The server socket queue length is now configurable 

Bugld:0 



revision 1.8.2.5 

date: 2004/08/27 23:46:50; author: harshad; state: Exp; 



lines: +36 -9 



Commenting out use of AlertThreadGroup and falling back to old code where in we kept 
a count of active threads. 

The threadgroup was not getting the correct count, the active count was always much 
higher. 

Bugld:SDR34822 
revision 1.8.2.4 

date: 2004/08/25 23:06:00; author: harshad; state: Exp; lines: +20 -4 
Bugld:SDR34822 

revision 1.8.2.3 

date: 2004/08/03 22:11:41; author: harshad; state: Exp; lines: +11 -30 

Adding AlertEngineThreadGroup to keep count of active threads and to find if there 

are any uncaught exceptions. 

Bugld:SDR32325 

revision 1.8.2.2 

date: 2004/04/21 00:17:55; author: harshad; state: Exp; lines: +1 -10 
Removing references to bwc, I had checked inthe code before the apr04 branch was 
cut. 
Bugld:0 
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cvslog 

revision 1.8.2.1 

date: 2004/04/08 00:03:30; author: harshad; state: Exp; lines: +6 -2 
server socket queue length is now configurable from propety file 
Bugid:0 
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Fwd Re RE sendmail Tuning 
Forwarded Message 

> From: Harshad Kamat <harshad@TeamOn.com> 

> To: Harshad Kamat <harshad@TeamOn.com>; Steve McCarthy 

> <sjm@teamon.com>; shaibal Roy <sroy@rim.net>; Michael zakharoff 

> <zak@TeamOn . com> 

> cc: Aaron Roberts <aaron@teamon.com>; Chris Lira <chris@teamon.com>; 

> David Hanson <davidh@teamon.com> 

> subject: Re: RE: sendmail Tuning 

> Date: Thu, 27 Mar 2003 10:43:28 -0800 (PST) 
> 

> 

> Another observation. 

> 

> if the SMSC is down and is not responding, the Alert Engine sends a 

> "554 Transaction failed" to Sendmail and Sendmail promptly bounces the 

> mail to error-handler, it does not queue it. 

> 

> Since it is lmtp, maybe it does not queue it and bounces it 

> immediately, if this is the case, we will jave to return a 421 instead 

> of 554 so that it puts it in the queue. 

> 

> - 

> Harshad N Kamat 

> TeamOn Systems 

> 425-369-5751 
> 

> Original Message 

> > From: Harshad Kamat <harshad@TeamOn.com> 

> > to: Michael Zakharoff <zak@TeamOn . com> ; shaibal Roy <sroy@rim.net>; 

> > Steve McCarthy 

> 

> > <sjm@teamon.com> 

> > Cc: Aaron Roberts <aaron@teamon.com>; Chris Lira <chris@teamon.com>; 

> > David Hanson <davidh@teamon.com> 

> > Subject: Re: RE: Sendmail Tuning 

> > Date: Thu, 27 Mar 2003 10:36:40 -0800 (PST) 

> > 

> > 

> > I have to run a test with TMboile at 2 pm where I will be sending a 

> > total of 21K alerts to 300 msisdns. 

> > 

> > I just ran a smaller version of that where I sent 3K mails to 300 msisdns. 

> > The observations are as follows. 

> > 1) Sendmail opened 371 connections to the AlertEngine to deliver 371 

> > alerts which resulted in 371 new connections being opened and 

> > subsequently closed to the SMSC. It got a busy signal for the 

> > remaining 2629 attempts and queued up the mails. 

> > 2) I ran sendmail -g -v to clear up the queue and it sent all these 

> > 2629 mails over a single connection. 

> > 

>> I am sure TMobile will not like the behavior described in 1) above. 

> > Hence, I don't want to run this configuration in production. There 

> > are two solutions. 

> > 1) Either we configure sendmail to queue all the mails and run the 

> > queue every 10 seconds or so. 

> > 2) I am going to introduce a connection pool for the SMSC connections. 

> > 

> > - 

> > Harshad N Kamat 

> > TeamOn Systems 

> > 425-369-5751 

> > 

> > Original Message 

Page 1 



Fwd Re RE Sendmail Tuning 

> > > From: Shaibal Roy <sroy@rim.net> 

> > > to: Michael Zakharoff <zak@TeamOn . com> 

> > > Cc: Harshad Kamat <harshad@TeamOn.com>; Steve McCarthy 

> > > <sim@TeamOn.com> 

> > > subject: RE: Sendmail Tuning 

> > > Date: Thu, 27 Mar 2003 13:18:29 -0500 

> > > 

> > > 

> > > Good info. THanks, Harshad. 

> > > 

> > > Mike: 

> > > 

> > > Some observations: 

> > > 

> > > 1) "if the ForkEachJob option is set, sendmail cannot use connection caching". 

> Out 

> > 

> > > config does not set this, right? 

> > > 

> > > 2) Should we consider running in "queue only" mode with a low queue interval? 

> > > 

> > > 3) what shall we set ConnectionCacheSize to? 4? 

> > > 

> > > Thanks. 

> > > 

> > > -shaibal 

> > > 

> > > original Message 

> > > From: Harshad Kamat [mailto:harshad@TeamOn.com] 

> > > sent: Thursday, March 27, 2003 10:04 AM 

> > > To: Michael Zakharoff; shaibal Roy; Steve McCarthy 

> > > Subject: Sendmail Tuning 

> > > 

> > > 

> > > http://www.sendmail.org/~ca/email/doc8.12/op-sh-4.html 

> > > 

> > > Harshad N Kamat 

> > > TeamOn Systems 

> > > 425-369-5751 

> > > 

> > > 

> > 
> 

> 
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Invention Disclosure Form: ID-TBD 



Version 0.3 



Instructions: 



• Fill in all sections of this form. 

• SAVE A LOCAL COPY. 

• Attach your local copy of this form to an email and 
send to patents@rim.net . 



Tracking Information: 

Unique ID: TBD 

(Reserved: To Be Determined (TBD) by the Patent Group) 



RIM Confidential and/or Solicitor-Client Privileged Work Product 
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Contact Information: 



Your Information: 

Name: Harshad N Kamat 

Email Address: hkamat@rim.net 

Phone ext.: (425)3695751 

RIM Location: RIM U.S. - TeamOn Systems 



Your Supervisor's Information: 

Name: Steve McCarthy 

Email Address: smccarthy@rim.net 



RIM Confidential and/or Solicitor-Client Privileged Work Product 
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M^zlffifi Invention Disclosure Form: ID-TBD 
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Short Title: [Enter Short Title Here] 



Question 1 

Who are the people whom you would consider to be inventors for this invention? 
Please list their names and email addresses , and include yourself if you believe you 
are an inventor: 



Harshad Kamat 
Shaibal Roy 



hkamat@rim.net 
srov@jim.net 



Question 2 

What do you call your invention (long title)? 

Universal Alert Engine 
Question 3 

Which of the following technical fields are relevant to your invention? Please check 
all that apply. 



Hardware 

□Power 

□Antenna 

□RF 

□ASIC 

□LCD 

□Keyboard 

□Speaker/Microphone 

□Thumbwheel 

□Cradle (device to desktop link) 
□Holster/Accessories 

Standards 

□30 

□CDMA 

□IDEN 

□EDGE 

□GPRS 

□GSM 

□UMTS 

□Mobitex/DataTAC 



Provide further details if needed: 

[Answer here] 

RIM Confidential and/or Solicitor-Client Privileged Work Product 



Software 

^Applications 

□Device Software 

□Device Firmware (incl. DSP) 

□OS 

g]Host Software (BES, MDS) 

□Web Client/ Internet Edition 

□Relay/Network 

□Java 

□Security 

□Protocol Stack (incl. TTPCOM & 3G) 

□UI 

□Phone 

□pos 

□Modem 
□Sync 
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Question 4 . .. 

What problem(s) does this invention address? Describe in detail. 

In a system where a user wants to be notified of an event by means of an alert the alert 
delivery engine needs to know the user's preferred alert mechanism. In order to deliver 
an alert to the user in his preferred medium, like e-mail, sms, wap etc., the alert delivery 
engine needs to have access to the user profiles. 

Howdoestfie invention solve the problem(s) identified in question 4? Describe in 
detail. 

The invention solves the problem by accepting the alert content in a generic format, like 
e-mail, and then delivers the alert to the intended user in his preferred medium, like e- 
mail, sms, or wap, based on certain properties of the alert content. 

Question 6 

If your invention can be described as: 

a) „ software or vror*** and related steps; please provide a flowchart and/or a logic 
diagram and corresponding written description clearly explaining the steps or 
sequences that comprise your invention; 

and/or 

b ) an apparatus or astern and related structure ; please provide a block diagram 
illustrating the various components of the apparatus/system and corresponding 
written description clearly explaining the various components and how they 
interact. 
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Version 0.3 

1 . Alerts are delivered to the Alert Engine over SMTP. 

2. Alert Engine queues up alerts in input queue. 

3. The Alert Engine pulls each alert from the queue and transforms it to the target 
delivery format be it sms, wap push, e-mail, pocket-pc over-the-air provisioning 
document and likewise based on certain headers and/or the format of the target 
address. 

4. The alert in the destination format is delivered to the appropriate gateway for that 
format. 



Include details on which part(s) of your block diagram and/or flowchart embody 
your invention. Your diagrams and description may be provided in separate 
attached files when submitting this document by email to patents(2)xim.net . 



Question 7 

Are you aware of any existing solutions that attempt to address the problem(s) 
outlined in question 4, if so please list them and provide a brief summary. Please 
spend a few minutes to search the web using http;//www.google.com/ and provide 
the two most relevant solutions you find. Note: please paste specific URLs and 
Keywords ! 

http://www.birlasoft.com/white/wirelesscontentdelivery.pdf [alert engine sms] 
http://otn.oracle.com/products/iaswe/htdocs/datasheet.p df [alert engine sms] 

Question 8 

For each solution listed in question 7, how is your solution different? Please describe 
in detail. If no existing solutions were found in answer to question 7, please proceed 
to question 9. 

For the BirlaSoft solution, it is not clear what the input format of the alert is. However, it 
appears as if the alert is delivered to the distribution engine in the output format desired 
by the user and the distribution engine performs no transformation. 

For the Oracle 9iAS Wireless Solution, the input format to the system can be from a 
variety of sources, the ones listed are HTTP, Local Files, FTP, and SQL in multiple 
formats. Also, the alert system seems to have access to the user's personal information 
and settings based on which it decides the output format for the alert. 

Question 9 



RIM Confidential and/or Solicitor-Client Privileged Work Product 




Page 
5 of 6 



f 



Invention Disclosure Form: ID-TBD 



Version 0.3 

Are you aware of any date(s) on which the invention, a product incorporating the 
invention, or any details relating to the invention may have been or is going to be 
released outside of RIM? If so, please provide the dates of any such releases. 

Disclosed to T-Mobile early '03. Confidentiality Clause in contract 

Question 10 

Is this submission a result of a "Patent Mining Session?" 
IE1YES 

□no 




Question 11 

Are you able to provide any further documents that relate to this invention (Le. 
design documents, specifications, drawings, sketches, rough ideas, etc)? If so, please 
attach the file(s) when submitting this document by email to patents@rim.net 

[Answer Here] 
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